Hello @bluejazzCHN
Before could you take a look a the following guide regarding the use of pre-commit
Instructions are available here: https://adafru.it/check-your-code
Let me know if you need any help. Thanks

@bluejazzCHN Hello, do you still want to work on this PR? let us know. Thanks.

@bluejazzCHN Hello, do you still want to work on this PR? let us know. Thanks.

read and try, it's also wrong. I don't know what I need to do.

Did you run pre-commit run --all-files could paste the error codes that this raise?

Thanks

Yeah Thanks I will take a look, I see that the problem is not in your code. I will take a look tonight and maybe do a PR on your repo if I could find the solution. Thanks :)

Ok now we are good, that was a tricky one for you info, sometimes Sphinx really, really really need their predefined spaces while parsing. That was the problem. Thanks :)

@jposada202020 it sound very good. thanks.

@bluejazzCHN No problem.
Need to find someone with this hardware to test, initial research return void values :)
@kattni could you help us here? is an animated gif could help as test?

I tried the original library with a Seeeduino Xiao the other day and have the same problem with (lack of) support for 4x8x8 displays. Now I found your pull request. First off, thanks for sharing!

The display I have is www.az-delivery.de/en/products/4-x-64er-led-matrix-display which is a plain 4x cascaded / chained MAX7219 unit. I have gotten this to work with code of my own. Let me check out this branch, review the code and see if it works. Will report, time permitting...

I tried the original library with a Seeeduino Xiao the other day and have the same problem with (lack of) support for 4x8x8 displays. Now I found your pull request. First off, thanks for sharing!

The display I have is www.az-delivery.de/en/products/4-x-64er-led-matrix-display which is a plain 4x cascaded / chained MAX7219 unit. I have gotten this to work with code of my own. Let me check out this branch, review the code and see if it works. Will report, time permitting...

@m9aertner looking forward to your results.

Hello, I was able to try out your code on my (DIY) test unit!

I am afraid I did not succeed in getting the display to work fully. I trust it's working for you, so I shall check my local environment some more for sure. Still, a couple of points that I noted:

1. It's great that you found and addressed the apparent bug on upstream master where self._chip_select.value in max7219.py does not get triggered properly. I wonder how that can have ever worked in upstream?
2. For some reason my display unit needs the self._chip_select.value inverted. It could also be that the Xiao with digitalio.DigitalInOut(A1) has a HW setting that does the inversion. I have wired A1, as in the original examples. Will check with a 'scope.
3. More on the software side, I see your point with passing the intended device number and number of devices (LED matrices) as additional parameters to the respective APIs. Personally, I think I would prefer to have the number of devices M (e.g. 4) as an immutable object property passed in once at construction time. Also, a "current" device might better be given to the object on demand, making it stateful in that respect, so that the rest of the API can remain as-is with respect to the original. In other words, you'd select LED matrix number 3 (or whatever) once, then use the same API as before and it would work on that current device number 3. Switch devices to 1...4 and repeat.
4. I understand your approach (and your grasp of the MAX datasheet :-) ) of sending 0,0 Noop commands for devices that are not currently targeted. Have you tried to use the already-utilized framebuffer object to just be sufficiently large to hold all LED data, and to send all of that data on every "show"? The amount of data sent would be up to four times smaller than when one updates a single device at a time, all the while sending Nops to all other devices. May as well send real data.
5. Last, from a "git" perspective, I believe you want to "squash" your commits before posting a Pull request. When merging to main it's usually best to have one commit that contains all the changes, which is easier to read, or just a very few commits. (Of course, it's not up to me to decide on the PR; personally I have not even achieved to set up the toolchain that tests a code contribution to become a valid Adafruit PR yet!).

Again, thanks so much for sharing your work!

So happy to see that there was a PR open for cascading 8x8 matrices, if only I had noticed it before I spent a few hours working on it myself. Unfortunately, I can't seem to get your implementation to work.

I'm using a Raspberry Pi 4 running Ubuntu 20.04, Python 3.9, and this matrix assembly with the following demo code:

from adafruit_max7219.matrices import Matrix8x8
from board import MOSI, SCLK, D25
import busio
import digitalio

import time

clk = SCLK
din = MOSI
cs = digitalio.DigitalInOut(D25)

spi = busio.SPI(clk, MOSI=din)

display = Matrix8x8(spi, cs, num=3)
display.brightness(1)
display.fill(0)
display.show()
time.sleep(0.5)

for x in range(24):
    for y in range(8):
        display.pixel(x, y, 1)
        display.show()
        time.sleep(0.1)

That results in this:

As you can see, it doesn't seem to cascade as expected. Using the same demo code, and a modified version of this RPi Pico MicroPython implementation, I get this:

The trick seems to be waiting to pull the chip select high until after all the displays have been addressed.

If the maintainers are interested I'd be happy to fork and try to update the existing codebase to accommodate the aforementioned modifications but I don't want to be rude any hijack this PR with another.

@FlantasticDan that would be great if you want to start working on implementing these modifications. This branch has conflicts now and it looks like a few folks tried it out unsuccessfully. OP has not commented in a little while. If they come back around perhaps they'd be willing to review / help test the next PR when it's ready.

I've opened #37 which implements my attempt at cascading MAX7219 chips. If anyone in this discussion is still willing and able, I'd love for you to test it out and provide any and all feedback.

Thanks for all of the preliminary work on this @bluejazzCHN and @m9aertner as well as @FlantasticDan for trying this out and reporting your findings.

This PR has conflicts currently and it sounds like there was trouble getting it running on Raspberry Pi. For now I think we can pick up the effort on this feature in #37 @kattni